Data transfer services in the wireless domain are known and certainly still evolving. Examples include SMS (short messaging service) and other SS7 control channel services. They can be used, for example, for text messaging. They do not affect the voice channels, but offer very limited bandwidth, so the amounts of data transferred are quite limited.
The WAP (Wireless Application Protocol) specifications and software offer some improved services. For example, they can be implemented to provide limited Internet access to a mobile unit. (We use the term “mobile unit” herein to refer broadly to any device with wireless connectivity, including without limitation a cell phone, PDA, laptop computer, palmtop, motor vehicle, etc.). The WAP services, however, require that the mobile unit itself be WAP enabled, and that the wireless carrier network also be WAP enabled. Thus, wireless carriers have to deploy and maintain WAP gateways at the edges of the network to provide WAP services. Some mobile units, and some networks or geographic areas may not be WAP enabled, so these services would not be available for data communication.
One approach to wireless data transfer that does not require changes in the wireless network infrastructure, although it requires specific implementation at both endpoints of a session, is the use of “in-band” data transfer. As the name implies, this technique transfers data in the voice channel, using carefully selected and timed audio frequency tones. (Commonly, wireless data transfer services do not use the voice channel at all.) In-band or voice channel data transfer can be done with little or no interruption of a voice conversation. Details of in-band signaling are explained in U.S. Pat. Nos. 6,144,336; 6,690,681 and 6,493,338 all incorporated wherein by this reference. These types of in-voice-channel data communications have two primary advantages: the wireless voice channel is reliable, and the technique works transparently across networks and carriers throughout the country and beyond. The data simply passes transparently through the voice service, as it “looks” like voice. However, in-band signaling provides only a very low bandwidth up to around 400 bps. That makes it almost useless for transferring significant amounts of data.
Higher bandwidth wireless data services are rapidly becoming available throughout the world. These services operate over dedicated data channels, not the voice channels. The newer specifications, so-called “3G” or third generation wireless technologies, while not yet widely implemented, promise packet data rates as follows, according to IMT-2000 standards:                2 Mbps for fixed environment        384 Mbps for pedestrian (i.e. slow-moving mobile unit)        144 kbps for vehicular traffic        
One problem, however, with virtually all wireless data services, is the difficulty in accessing those services in a network “polling” type of application. Polling (or “pulling data”) here refers to contacting a mobile unit to pull or retrieve digital data needed by a requester. (The “requester” typically would be an application program.) Preferably, an authorized requester should be able to poll remote mobile units, and fetch data, without manual user intervention at the remote location. In other words, a polling process should be able to be completely automated, although for some applications it can be advantageously initiated by a user at the requester end.
To illustrate, a wireless automated inventory control system may seek to poll units, say trucks or tanks, to learn their present location, fuel supply, operator ID, etc. A packet data connection, for example an IP connection, cannot be established with a mobile unit from the network side (we call this “network initiated”) using prior technology, because the mobile device has no predetermined IP address. Rather, an IP address is dynamically assigned to a mobile unit only if and when it initiates a session to an IP network. Accordingly, a user application cannot poll a remote mobile unit to establish a packet data transfer session using known technologies.
A system has been suggested for IP addressing of GPRS mobile terminals that purportedly would enable TCP/IP connection without a phone call. That proposal recognized that there are not enough IP addresses available (under the current Ipv4 regime) to assign one to every wireless terminal. The proposal calls for a combination of Public Addresses (registered with public routing tables) and Private addresses, not to be routed on the public Internet. Rather, the private (IP-like) addresses would only be used within a GPRS operator's own network. This would require network address translation (NAT) facilities and is generally impractical. Even if implemented, such a scheme does not solve the problem that the mobile (or wireless) terminal address is unknown, and is not publicly discoverable in a convenient way.
The need remains for a convenient and effective way to poll a remote mobile unit, that is, to request a data packet session, for uploading or downloading data via the wireless network, without changing the wireless carrier infrastructure and in a manner compatible with existing packet data networks and protocols such as IP.